home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000049_rts _Thu Mar 25 09:06:17 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  2KB
  1. Received: from boojum.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
  2.     id AA17665; Thu, 25 Mar 1993 09:06:19 MST
  3. Date: Thu, 25 Mar 1993 09:06:17 MST
  4. From: "Rick Snodgrass" <rts>
  5. Message-Id: <199303251606.AA29330@boojum.cs.arizona.edu>
  6. Received: by boojum.cs.arizona.edu; Thu, 25 Mar 1993 09:06:17 MST
  7. To: tsql@cs.arizona.edu
  8. Subject: schema extensions
  9.  
  10. Ed Robertson makes the cogent argument that it is good design dictates
  11. completing the eventual schema now, rather than starting with a small
  12. schema and incrementally extending it in the future.
  13.  
  14. I and others have made the point that a larger initial schema is
  15. counter to the goal of comprehensiveness. Specifically, if a larger
  16. schema is adopted, then the number of possible queries grows very
  17. quickly, making it difficult to get an initial version of the
  18. benchmark completed. I feel strongly that we need to be very careful
  19. not to be too ambitious this first time around.  It is very important
  20. that we produce *something* soon, that can then be generalized and
  21. extended.
  22.  
  23. How about the following?
  24.  
  25. 1. We design the schema to include the additional attributes. This
  26. will involve some more discussion to ensure that we have the right
  27. ones, and that we don't have too much "functional redundancy" (i.e.,
  28. it doesn't seem that we need two time-invariant attributes, or two
  29. user-defined attributes, or two multi-valued attributes). Perhaps Ed
  30. or Patrick could produce a strawman proposal by augmenting the latex
  31. prose that Christian sent out previously.
  32.  
  33. 2. In the first draft, we present the schema in two parts. The first
  34. will contain the entire schema. The second part, where we discuss
  35. restrictions applied in this first draft, we identify the subset of
  36. attributes that queries *in this first draft* could mention. This is
  37. very similar to restricting ourselves to not include updates or
  38. aggregates. In future versions, the set of attributes allowed in
  39. queries could grow, until all are allowed to be used, at which time
  40. the second part, on the restrictions, could simply be removed from the
  41. document.
  42.  
  43. Could the others who have proposed benchmarks in the past comment on
  44. how you think we ought to proceed?